1. Technical Field
The present invention relates in general to a system and method for gathering data regarding receivers of multicast content. In particular, the present inventions relates to a system and method for transmitting multicast receiver data back to a content producer sending content to a multicast content through a computer network, such as the Internet.
2. Description of the Related Art
Many emerging Internet applications are one-to-many or many-to-many, where one or multiple sources are sending to multiple receivers. Examples are the transmission of corporate messages to employees, communication of stock quotes to brokers, video and audio conferencing for remote meetings and telecommuting, and replicating databases and web site information. IP Multicast supports this type of transmission by enabling sources to send a single copy of a message to multiple recipients who explicitly want to receive the information. This is more efficient than requiring the source to send an individual copy of a message to each requester (referred to as point-to-point unicast), in which case the number of receivers is limited by the bandwidth available to the sender. It is also more efficient than broadcasting one copy of the message to all nodes (broadcast) on the network, since many nodes may not want the message, and because broadcasts are limited to a single subnet.
Multicast is a receiver-based concept: receivers join a particular multicast session group and traffic is delivered to all members of that group by the network infrastructure. In a traditional system, the sender does not maintain a list of receivers. Only one copy of a multicast message passes over any link in the network, and copies of the message are made only where paths diverge at a router.
The membership of a group is dynamic; that is, receivers may join and leave groups at any time. There is no restriction on the location or number of members in a group. A receiver may also be a member of more than one group at a time. In addition, at the application level, a single group address may have multiple data streams on different port numbers, on different sockets, in one or more applications. Multiple applications may share a single group address on a receiver's computer system.
To support native IP Multicast, the sending and receiving nodes and network infrastructure between them are each multicast-enabled, including any intermediate routers. Requirements for native IP Multicast at the end node hosts include: (i) support for IP Multicast transmission and reception in the TCP/IP protocol stack; (ii) software supporting the Internet Group Management Protocol (IGMP) to communicate requests to join a multicast group(s) and receive multicast traffic; (iii) network interface cards and drives which efficiently filter for LAN data link layer addresses mapped from network layer IP Multicast addresses; (iv) IP Multicast application software, such as for video conferencing; and (v) IP Multicast enabled intermediate routers between the sender(s) and receiver(s). Many new routers have support for IP Multicast. Older ones may require more memory before they can be upgraded.
IP Multicast has broad and growing industry backing, and is supported by many vendors of network infrastructure elements such as routers, switches, TCP/IP stacks, network interface cards, desktop operating systems and application software.
FIG. 1a shows a prior art depiction of content producer 100 sending content to several clients using multicast enabled routers. Content producer 100 sends the content to sender's subnet 102 where the content is received by two clients (clients 103 and 106) connected to the sender's subnet. These clients previously joined the multicast group to which the content was sent. Two other clients (108 and 110) are also connected to the sender's subnet but do not receive the content because they did not join the group to which the content was sent.
Sender's subnet 102 includes multicast enabled router 112 which forwards the content to multicast enabled router 114 which is interconnected to multicast enabled internetwork 116. The content travels through multicast enabled internetwork 116 on its way to other clients who joined the group but are not connected to the sender's subnet, such as clients connected to receiver's subnet 122.
The content arrives at multicast enabled router 118 which forwards the content to multicast enabled router 120 that is included in receiver's subnet 122. The content is transmitted by multicast enabled router 120 to clients within receiver's subnet 122. Two of the clients (124 and 126) included in receiver's subnet 122 previously joined the group to which the content was sent and therefore receive the content. Two other clients (128 and 130) are included in the receiver's subnet but do not receive the content because they did not join the group to which the content was sent.
IP Multicast can be optimized in a LAN by using multicast filtering switches. An IP Multicast-aware switch provides the same benefits as a multicast router, but in the local area. Without one, the multicast traffic is sent to all segments on the local subnet. An IP Multicast aware switch can automatically set up multicast filters so the multicast traffic is only directed to the participating end nodes.
FIG. 1b shows a prior art depiction of multicast enabled filtering switches. Network 150, such as the Internet, transmits multicast content that is received by multicast enabled router 160. Multicast enabled router 160 transmits the content to multicast filtering switch 170. Multicast filtering switch 170 determines which downstream switches have previously joined the multicast group to which the content is being sent. In the example shown, downstream multicast filtering switch 180 is connected to two devices that have joined the group (receiver 182 and receiver 186) and one device that has not joined the group (non-receiver 184). Because there is at least one device that joined the group, MC filtering switch 170 transmits the content onto MC filtering switch 180 for further transmission to the devices. On the other hand, MC filtering switch 190 has no receiving devices (only non-receiving devices 192, 194, and 196), therefore the content is not forwarded from MC filtering switch 170 to MC filtering switch 190.
IP Multicast uses Class D Internet Protocol addresses—those with 1110 as their high-order four bits—to specify multicast groups. In Internet standard “dotted decimal” notation, group addresses range from 224.0.0.0 to 239.255.255.255. Two types of group addresses are supported: permanent and temporary. Examples of permanent addresses, as assigned by the Internet Assigned Numbers Authority (IANA), are 224.0.0.1, the “all-hosts group” used to address all IP Multicast receivers on the directly connected network, and 224.0.0.2, which addresses all routers on a LAN. The range of addresses between 224.0.0.0 and 224.0.0.255 is reserved for routing protocols and other low-level topology discovery or maintenance protocols. Other addresses and ranges have been reserved for applications, such as 224.0.13.000 to 224.0.13.255 for Net News.
To send an IP Multicast data stream, the sender specifies an appropriate destination address, which represents a group. IP Multicast data streams are sent using the same “Send IP” operation used for unicast data streams. Compared to sending of IP Multicast data streams, reception of IP Multicast data streams is more complex, particularly over a WAN.
To receive data streams, a user's application requests membership in the multicast group associated with a particular multicast (e.g. “I want to view today's baseball game”). This membership request is communicated to the LAN router and, if necessary, on to intermediate routers between the sender and the receiver. As another consequence of its group membership request, the receiving computer's network interface starts filtering for the LAN-specific hardware (data-link layer) address associated with the new multicast group address.
Wide Area Network (WAN) routers deliver the requested incoming multicast data streams to the LAN router, which maps the group address to its associated hardware address and builds the message (for example, an Ethernet frame) using this address. The receiving computer's network interface card and network driver, listening for these addresses, pass the multicast messages to the TCP/IP protocol stack, which makes them available as input to the user's application, such as a video viewer.
Whereas an IP unicast address is statically bound to a single local network interface on a single IP network, an IP group address is dynamically bound to a set of local network interfaces on a set of IP networks. An IP group address is not bound to a set of IP unicast addresses. Multicast routers do not know the list of receivers for each group—only the groups for which there is one member on the subnetwork. A multicast router attached to an Ethernet need associate only a single Ethernet multicast address with each group having a local member.
Each IP Multicast packet uses the time-to-live (TTL) field of the IP header as a scope-limiting parameter. The TTL field controls the number of hops that an IP Multicast packet is allowed to propagate. Each time a router forwards a packet, its TTL is decremented. A multicast packet whose TTL has expired (is 0) is dropped, without an error notification to the sender. This mechanism prevents messages from needless transmission to regions of the worldwide Internet that lie beyond the subnets containing the multicast group members.
A local network multicast reaches all immediately-neighboring members of the destination group (the IP TTL is 1 by default). If a multicast data stream has a TTL greater than 1, the multicast router(s) attached to the local network take responsibility for internetwork forwarding (see FIG. 1a for an example). The data stream is forwarded to other networks that have members of the destination group. On those other member networks that are reachable within the IP time-to-live, an attached multicast router completes delivery by transmitting the data stream as a local multicast. TTL thresholds in multicast routers prevent data streams with less than a certain TTL from traversing certain subnets. This can provide a mechanism for confining multicast traffic to within campus or enterprise networks.
Multicast packets from remote sources are relayed by routers, which forwards them on to the local network if there is a recipient for the multicast group on the LAN. The Internet Group Management Protocol (IGMP) is used by multicast routers to identify the existence of group members on their directly attached subnets. These routers do so by sending IGMP queries and having receivers report their group memberships.
IGMP messages are encapsulated in IP data streams. IGMP has two kinds of packets: Membership Query and Membership Report. To determine if any computers on a local subnet belong to a multicast group, one multicast router per subnet periodically sends a hardware (data link layer) multicast IGMP Membership Query to all IP end nodes on its LAN, asking them to report back on the group memberships of their processes. This query is sent to the all-hosts group (network address 224.0.0.1) and a TTL of 1 is used so that these queries are not propagated outside of the LAN. Each computing device sends back one IGMP Membership Report message per group, sent to the group address, so all group members see it (thus only one member reports membership). When a process asks its computing device to join a new multicast group, the driver creates a hardware multicast address, and an IGMP Membership Report with the group address is sent. The device's network interface maps the IP host group addresses to local network addresses as required to update its multicast reception filter. Each device keeps track of its group memberships, and when the last process on a device leaves a group, that group is no longer reported by the device. Periodically the local multicast router sends an IGMP Membership Query to the “all-hosts” group, to verify current memberships. If all member hosts reported memberships at the same time frequent traffic congestion might result. This is avoided by having each device delay its report by a random interval if it has not seen a report for the same group from another device. As a result, only one membership report is sent in response for each active group address, although many hosts may have memberships. One challenge that arises as a result is that devices, such as routers, do not know the number of receivers for a group.
IGMP updates are used by multicast routing protocols to communicate host group memberships to neighboring routers, propagating group information through the internetwork. IGMP is used to identify a designated router in the LAN for this purpose.
The Internet includes a multitude of subnetworks connected by routers. When the source of a message is located on one subnet and the destination is located on a different subnet, the IP protocol determines how to get from the source to the destination. Each device on the Internet has an address that identifies its physical location; part of the address identifies the subnet on which it resides and part identifies the particular device on that subnet. Routers periodically send routing update messages to adjacent routers, conveying the state of the network as perceived by that particular router. This data is recorded in routing tables that are then used to determine optimal transmission paths for forwarding messages across the network.
Unicast transmission involves transmission from a single source to a single destination. Thus, the transmission is directed towards a single physical location that is specified by the host address. The routing procedure, as described above, is relatively straightforward because of the binding of a single address to a single host.
FIG. 2 is a prior art depiction of a routing map that may be used for unicast transmissions. In the example shown, there are several possible paths to transmit the unicast transmission from one router to another. Router 200 can send a transmission to router 290 and it can pass through a number of different routers. Router 200 is connected to two routers, 210 and 220. Router 210, in turn, is connected to two other routers, 230 and 225, while router 220 is also connected to router 225 as well as router 240. Router 225 is connected to four different routers—210, 220, 250, and 260. Router 250 and 260 are also shown being connected to four routers, router 250 connected to routers 225, 230, 260, and 280, while router 260 is connected to routers 225, 240, 250, and 290. Needless to say, there are multiple ways a unicast transmission can be sent to any given router.
Routing multicast traffic adds complexity. A multicast address identifies a particular transmission session, rather than a specific physical destination. An individual host is able to join an ongoing multicast session, by using IGMP to communicate this desire to its subnet router. One approach to sending data to multiple receivers would be for the source to maintain a table identifying all the receiving subnets participating in the session and to send a separate copy of the data to each receiving subnet. However, this would be an inefficient use of bandwidth, since many of the data streams would follow the same path throughout much of the network. Techniques have been developed to address the problem of efficiently routing multicast traffic. Since the number of receivers for a multicast session can potentially be quite large, the source should not need to know all the relevant addresses. Instead, the network routers are able to translate multicast addresses into host addresses. The basic principle involved in multicast routing is that routers interact with each other to exchange information about neighboring routers. To avoid duplication of effort, a single router is selected (via IGMP) as the Designated Router for each physical network.
For efficient transmission, Designated Routers construct a “spanning tree” that connects all members of an IP Multicast group. A spanning tree has enough connectivity so that there is only one path between every pair of routers, and it is loop-free. If each router knows which of its lines belong to the spanning tree, it can copy an incoming multicast data stream onto all of its outgoing branches, generating only the minimum needed number of copies. Messages are replicated only when the tree branches, thus minimizing the number of copies of the messages that are transmitted through the network. Since multicast groups are dynamic, with members joining or leaving a group at any time, the spanning tree is dynamically updated. Branches in which no listeners exist are discarded (pruned). A router selects a spanning tree based on the network layer source address of a multicast packet, and prunes that spanning tree based on the network layer destination address.
FIG. 3 is a prior art depiction of a spanning tree created from the router configuration shown in FIG. 2. As can be seen, there is now only one path a transmission can take to reach any given router. Starting at router 300, transmissions destined for subnets covered by routers 310, 330, or 370 take the left most branch from router 300. Transmissions destined for other subnets covered by routers 320, 325, 350, 380, 340, 360, or 390 take the right most branch from router 300. Router 320 is used to branch messages between its left branch which covers routers 325, 350, and 380, and its right branch which covers routers 340, 360, and 390. Multicast transmissions use the spanning tree shown in FIG. 3 to ensure that any given subnet only receives one copy of the transmission, thus conserving network bandwidth.
While traditional multicast networks provide many opportunities, they also present certain challenges with delivering content to receivers. The content producer is unable to determine the number of receivers that have joined groups to receive content. This is a particular challenge for pay-per-view content distributions where the producer is supposed to be paid by receivers and would like to reduce or eliminate the number of devices that receive the content without paying for it. What is needed, therefore, is a system and method that provides the content producer with information regarding multicast receivers. These statistics can then be used by the producer in a number of ways, including reducing or eliminating the number of non-paying receivers for pay-per-view content.